Approvers:

• myakove
• rnetser

Reviewers:

• myakove
• rnetser

• hold
• verified
• wip
• lgtm
• approve
• automerge

• Conventional Title: Mode: fix (claude/claude-opus-4-6-1m)
• Cherry-Pick Conflict Resolution: Enabled (claude/claude-opus-4-6-1m)
• Test Oracle: Triggers: approved (claude/claude-opus-4-6[1m]); /test-oracle can be used anytime

• Suspicious Path Detection: Monitors paths: .claude/, .vscode/, .cursor/, .devcontainer/, .pi/, .github/workflows/, .github/actions/
• Committer Identity Check: Verifies last committer matches PR author
• Mandatory: Security checks block merge (use /security-override to bypass — maintainers only)

• Add welcome-extra-info config option (global and per-repo) for markdown appended to welcome
 messages.
• Support repo file override via .github-webhook-server-welcome-message.md with size/UTF-8
 validation.
• Render a new “Additional Information” section in the PR welcome comment and add unit coverage.

graph TD
  E{{"GitHub webhook event"}} --> P["GithubWebhook.process"] --> R["Resolve extra info"] --> H["PullRequestHandler"] --> C{{"Create welcome comment"}}
  Y["Config (welcome-extra-info)"] --> R
  F[(".github-webhook-server-welcome-message.md")] --> R
  subgraph Legend
    direction LR
    _ext{{"Event/External"}} ~~~ _svc["Service/Logic"] ~~~ _store[("Repo content")]
  end

Loading

The following are alternative approaches to this PR:

1. Config-only extra info (no repo file)

• ➕ Avoids an extra GitHub API call to fetch repo content
• ➕ Keeps all customization centralized in the service config
• ➖ Harder for repo owners to self-serve changes without changing shared config
• ➖ Less discoverable than a repo-local markdown file

2. Read the markdown override from the cloned repo checkout

• ➕ Avoids an additional GitHub contents API call (uses already-cloned files)
• ➕ Keeps content retrieval consistent with other local-file processing
• ➖ Requires cloning earlier/more often for events that currently don’t need it
• ➖ May add I/O and lifecycle complexity around when the repo is available locally

3. Template-based welcome message customization

• ➕ More structured customization (placeholders, conditional blocks)
• ➕ Can prevent malformed markdown and enforce layout
• ➖ Adds complexity and potential security/escaping issues
• ➖ Requires documenting a templating language and maintaining compatibility

Recommendation: The chosen approach (simple markdown injection with a clear precedence chain and explicit “empty suppresses” semantics) is pragmatic and repo-owner friendly. If GitHub API call volume becomes a concern, consider switching the file override to be read from the local clone where feasible, but the current implementation is appropriate for this scope.

Enhancement (2) +76 / -0

github_api.pyResolve welcome extra info from config and optional repo markdown file +62/-0

Resolve welcome extra info from config and optional repo markdown file

• Introduces 'welcome_extra_info' field, loads it via 'config.get_value()', and conditionally fetches '.github-webhook-server-welcome-message.md' for relevant events. Adds file size enforcement (10KB), UTF-8 validation, and graceful fallback behavior on missing/invalid content.

webhook_server/libs/github_api.py

pull_request_handler.pyRender “Additional Information” section in welcome comment +14/-0

Render “Additional Information” section in welcome comment

• Appends a new markdown section after the Tips block when 'welcome_extra_info' is non-empty, injecting content as-is.

webhook_server/libs/handlers/pull_request_handler.py

Tests (2) +209 / -2

test_github_api.pyAdd unit tests for repo file loading and precedence behavior +110/-2

Add unit tests for repo file loading and precedence behavior

• Adds async tests covering success, missing file, oversized content, list responses, empty file suppression, unicode decode failure, and generic exception fallback while preserving config value when appropriate.

webhook_server/tests/test_github_api.py

test_pull_request_handler.pyAdd unit tests for welcome extra info section rendering +99/-0

Add unit tests for welcome extra info section rendering

• Adds tests asserting the section is omitted for empty/None values and rendered correctly for single and multi-line markdown content.

webhook_server/tests/test_pull_request_handler.py

Documentation (1) +6 / -0

config.yamlDocument 'welcome-extra-info' usage in example config +6/-0

Document 'welcome-extra-info' usage in example config

• Adds commented example YAML showing how to provide multi-line markdown for the new welcome extra info section.

examples/config.yaml

Other (1) +14 / -0

schema.yamlAdd 'welcome-extra-info' to global and per-repo schema +14/-0

Add 'welcome-extra-info' to global and per-repo schema

• Extends the config schema with a 'welcome-extra-info' string (10KB max) at both global and per-repo levels, documenting override and explicit-empty semantics.

webhook_server/config/schema.yaml

Description

New tests assert that non-string and over-10KB welcome-extra-info values still load successfully,
which contradicts the requirement that schema validation reject invalid types/lengths. This weakens
automated detection of schema regressions for the new field.

Code

webhook_server/tests/test_config_schema.py[R1027-1075]

+    def test_welcome_extra_info_global_type_violation(
+        self, valid_minimal_config: dict[str, Any], monkeypatch: pytest.MonkeyPatch
+    ) -> None:
+        """Test that welcome-extra-info with integer type still loads (runtime guard handles it)."""
+        config = valid_minimal_config.copy()
+        config["welcome-extra-info"] = 12345
+
+        temp_dir = self.create_temp_config_dir_and_data(config)
+
+        try:
+            monkeypatch.setenv("WEBHOOK_SERVER_DATA_DIR", temp_dir)
+
+            config_obj = Config()
+            assert config_obj.root_data["welcome-extra-info"] == 12345
+        finally:
+            shutil.rmtree(temp_dir)
+
+    def test_welcome_extra_info_repository_level(
+        self, valid_minimal_config: dict[str, Any], monkeypatch: pytest.MonkeyPatch
+    ) -> None:
+        """Test valid welcome-extra-info at per-repo level."""
+        config = valid_minimal_config.copy()
+        config["repositories"]["test-repo"]["welcome-extra-info"] = "Repo-specific welcome info."
+
+        temp_dir = self.create_temp_config_dir_and_data(config)
+
+        try:
+            monkeypatch.setenv("WEBHOOK_SERVER_DATA_DIR", temp_dir)
+
+            config_obj = Config()
+            repo_data = config_obj.root_data["repositories"]["test-repo"]
+            assert repo_data["welcome-extra-info"] == "Repo-specific welcome info."
+        finally:
+            shutil.rmtree(temp_dir)
+
+    def test_welcome_extra_info_max_length(
+        self, valid_minimal_config: dict[str, Any], monkeypatch: pytest.MonkeyPatch
+    ) -> None:
+        """Test that welcome-extra-info exceeding 10240 chars loads (runtime guard handles it)."""
+        config = valid_minimal_config.copy()
+        config["welcome-extra-info"] = "x" * 10241
+
+        temp_dir = self.create_temp_config_dir_and_data(config)
+
+        try:
+            monkeypatch.setenv("WEBHOOK_SERVER_DATA_DIR", temp_dir)
+
+            config_obj = Config()
+            assert len(config_obj.root_data["welcome-extra-info"]) == 10241

Relevance

⭐⭐⭐ High

Team previously accepted strengthening schema tests to assert schema.yaml enforces types/structures
(#1112); tests asserting invalid values “still load” conflicts.

PR-#1112

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1523313 requires automated tests to verify schema rejects invalid types/structures
for welcome-extra-info. The added tests explicitly assert that an integer value and an over-limit
string are accepted/loaded, which fails that requirement.

Add schema validation tests for welcome-extra-info
webhook_server/tests/test_config_schema.py[1027-1041]
webhook_server/tests/test_config_schema.py[1062-1075]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new tests for `welcome-extra-info` currently assert that invalid values (non-string type and >10KB length) still load successfully. Per compliance, schema validation tests must ensure invalid configurations are rejected.

## Issue Context
- The schema defines `welcome-extra-info` as `type: string` with `maxLength: 10240`.
- The added tests currently encode the opposite expectation (that invalid type/length still loads), which prevents tests from catching schema validation regressions.

## Fix Focus Areas
- webhook_server/tests/test_config_schema.py[1027-1075]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

Newly added pytest fixtures/tests introduce functions with untyped parameters and missing return
type annotations. This violates the requirement for full type annotations on all modified/added
function and method signatures.

Code

webhook_server/tests/test_github_api.py[R2820-2830]

+    @pytest.fixture()
+    def github_webhook(self, process_github_webhook):
+        """Create a GithubWebhook instance for welcome extra info tests."""
+        gw = process_github_webhook
+        gw.welcome_extra_info = "config value"
+        gw.repository = MagicMock()
+        return gw
+
+    @pytest.mark.asyncio()
+    async def test_load_from_file_success(self, github_webhook):
+        content_file = MagicMock()

Relevance

⭐⭐⭐ High

Type-annotation gaps in tests were previously flagged and accepted fixes (PR #968, #1123).

PR-#968
PR-#1123

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 1523029 requires explicit type annotations for every parameter and an explicit return type. The
added fixture and async tests omit parameter annotations and return annotations.

Rule 1523029: Require full type annotations on all function and method signatures
webhook_server/tests/test_github_api.py[2820-2830]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New test functions/fixtures are missing parameter and return type annotations.

## Issue Context
Compliance requires explicit type annotations on all added/modified function and method signatures, including tests.

## Fix Focus Areas
- webhook_server/tests/test_github_api.py[2820-2922]
- webhook_server/tests/test_pull_request_handler.py[3301-3396]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

The schema adds welcome-extra-info fields but no automated schema validation tests were added to
cover valid/invalid cases for the new field. This risks regressions where invalid configs may be
accepted (or valid configs rejected) without detection.

Code

webhook_server/config/schema.yaml[R254-260]

+  welcome-extra-info:
+    type: string
+    maxLength: 10240
+    description: |
+      Additional information to display at the end of the PR welcome message (global default).
+      Content is injected as-is (markdown). Can be overridden per-repo.
+      An empty string explicitly clears any inherited value.

Relevance

⭐⭐⭐ High

Team previously required adding tests when extending schema (accepted in PR #1112).

PR-#1112

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

Rule 1523313 requires automated schema validation tests for the new welcome-extra-info field at
global and per-repo scope. The PR adds the field to the schema, but there is no corresponding test
coverage added/updated to validate it.

Add schema validation tests for welcome-extra-info
webhook_server/config/schema.yaml[254-260]
webhook_server/config/schema.yaml[533-539]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The schema introduces `welcome-extra-info` but the test suite does not add coverage validating correct schema behavior (valid types, maxLength, invalid types) for both global and per-repo scopes.

## Issue Context
A dedicated compliance requirement exists to add schema validation tests for this new field.

## Fix Focus Areas
- webhook_server/config/schema.yaml[254-260]
- webhook_server/config/schema.yaml[533-539]
- webhook_server/tests/test_config_schema.py[12-200]
- webhook_server/tests/test_schema_validator.py[47-200]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

GithubWebhook.process() preloads .github-webhook-server-welcome-message.md on pull_request
opened/ready_for_review, but PullRequestHandler.process_new_or_reprocess_pull_request() loads the
same file again when creating the welcome comment. This causes an avoidable second get_contents()
call on the common path where a welcome comment is created (including draft→ready_for_review).

Code

webhook_server/libs/github_api.py[R696-701]

+            if self.github_event == "pull_request" and self.hook_data.get("action") in (
+                "opened",
+                "ready_for_review",
+            ):
+                await self.load_welcome_extra_info_from_file()
+

Relevance

⭐⭐⭐ High

Team previously accepted refactors to eliminate duplicate API work/caching (e.g., avoid double user
enumeration, cache API lookups).

PR-#1117
PR-#906
PR-#1036

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

GithubWebhook.process() unconditionally calls load_welcome_extra_info_from_file() for
pull_request opened/ready_for_review, and the pull request handler calls it again when it
determines a welcome comment needs to be created, resulting in duplicate repository get_contents()
work on that common path.

webhook_server/libs/github_api.py[696-701]
webhook_server/libs/handlers/pull_request_handler.py[1975-1980]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The welcome-extra-info markdown file is fetched twice during welcome-comment creation for `pull_request` `opened` / `ready_for_review` events: once in `GithubWebhook.process()` and again in `PullRequestHandler.process_new_or_reprocess_pull_request()`.

### Issue Context
The handler already loads the file only when it is about to build a welcome message (and only when a welcome comment doesn’t exist). The earlier preload in `GithubWebhook.process()` is therefore redundant for these paths and costs an extra GitHub API call.

### Fix Focus Areas
- webhook_server/libs/github_api.py[696-701]
- webhook_server/libs/handlers/pull_request_handler.py[1975-1980]

### Implementation guidance
Choose one of:
1) Remove the preload from `GithubWebhook.process()` and rely on the handler(s) to call `load_welcome_extra_info_from_file()` only when building/regenerating the welcome message.
2) Add a small memoization flag on `GithubWebhook` (e.g., `welcome_extra_info_file_checked: bool`) so subsequent calls within the same webhook instance become no-ops.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

GithubWebhook.process() eagerly calls load_welcome_extra_info_from_file() for pull_request
action reopened, but the reopened handler path does not build a welcome comment, so the file
fetch does not affect output. This adds unnecessary GitHub API traffic and latency on every reopen
event.

Code

webhook_server/libs/github_api.py[R696-701]

+            if self.github_event == "pull_request" and self.hook_data.get("action") in (
+                "opened",
+                "reopened",
+                "ready_for_review",
+            ):
+                await self.load_welcome_extra_info_from_file()

Relevance

⭐⭐⭐ High

Team often accepts reducing unnecessary webhook work/API calls in github_api.py (early-exit/skip
heavy ops in PRs 1039,1036).

PR-#1039
PR-#1036

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The webhook layer fetches the file for reopened, but the PR handler only creates a welcome comment
on opened/ready_for_review, and welcome_extra_info is only used when composing the welcome
comment, so the reopened fetch cannot change behavior.

webhook_server/libs/github_api.py[696-702]
webhook_server/libs/handlers/pull_request_handler.py[254-266]
webhook_server/libs/handlers/pull_request_handler.py[695-706]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`GithubWebhook.process()` loads `.github-webhook-server-welcome-message.md` for `pull_request` actions including `reopened`, but `PullRequestHandler` does not create a welcome comment on `reopened`, so the load is wasted.

### Issue Context
`welcome_extra_info` is only consumed when generating the welcome comment (`_prepare_extra_info_welcome_section`), and welcome comment creation is only performed for `opened` and `ready_for_review` in the `pull_request` handler.

### Fix Focus Areas
- webhook_server/libs/github_api.py[696-702]
- webhook_server/libs/handlers/pull_request_handler.py[254-266]

### Implementation notes
- Option A (minimal): Remove `"reopened"` from the action tuple in `GithubWebhook.process()`.
- Option B (cleaner ownership): Move the file-load to `PullRequestHandler.process_pull_request_webhook_data()` just before building/creating the welcome comment (only in the `opened`/`ready_for_review` branch), and remove the eager load from `GithubWebhook.process()` entirely.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

process_new_or_reprocess_pull_request() always calls load_welcome_extra_info_from_file() before
checking whether a welcome comment already exists, so /reprocess pays an avoidable repo
get_contents() call when the welcome comment is already present. This adds unnecessary latency and
consumes GitHub API rate limit without affecting output.

Code

webhook_server/libs/handlers/pull_request_handler.py[R1975-1977]

+        # Load file-based welcome extra info before building the welcome message
+        await self.github_webhook.load_welcome_extra_info_from_file()
+

Relevance

⭐⭐⭐ High

Team often accepts reducing unnecessary API work/early-exits (perf PRs like #906, #930; handler
optimizations accepted in #894).

PR-#906
PR-#930
PR-#894

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The handler loads extra info from the repo file before it checks whether the welcome comment exists;
when the comment exists, the method never builds/creates a welcome message, making the file load
unnecessary on that path.

webhook_server/libs/handlers/pull_request_handler.py[1967-1989]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
`process_new_or_reprocess_pull_request()` loads `.github-webhook-server-welcome-message.md` unconditionally, even though the method only needs the extra info when it is about to *create* a welcome comment.

### Issue Context
This path is used by the `/reprocess` command. If a welcome comment already exists, the code skips creating a new welcome comment, but it still performs a repo contents fetch.

### Fix Focus Areas
- webhook_server/libs/handlers/pull_request_handler.py[1975-1986]

### Suggested change
Move `await self.github_webhook.load_welcome_extra_info_from_file()` inside the `if not await self._welcome_comment_exists(...)` branch (right before `_prepare_welcome_comment()`), so the file is fetched only when a welcome message will actually be created.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

When welcome-extra-info exceeds the 10KB limit, _repo_data_from_config() logs a warning without
self.log_prefix, making it difficult to attribute the warning to a specific repo/webhook instance
in multi-repo deployments.

Code

webhook_server/libs/github_api.py[R1132-1134]

+            if _byte_len > 10240:
+                self.logger.warning(f"welcome-extra-info exceeds 10KB limit ({_byte_len} bytes). Ignoring.")
+                self.welcome_extra_info = ""

Relevance

⭐⭐⭐ High

Team frequently enforces/accepts adding log_prefix for diagnostic logs (accepted in PR #998;
traceability focus in PR #808).

PR-#998
PR-#808

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The oversize warning lacks self.log_prefix, while nearby warnings (including the file-size warning
for the markdown override) include the prefix, demonstrating an inconsistency that reduces
traceability.

webhook_server/libs/github_api.py[1121-1134]
webhook_server/libs/github_api.py[1183-1188]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The oversize warning for `welcome-extra-info` is emitted without `self.log_prefix`, unlike most other warnings in this module. This reduces diagnosability because the log line can’t be tied to a specific repo/webhook execution.

### Issue Context
Other warnings in `GithubWebhook` consistently include `self.log_prefix` (or a `getattr(self, "log_prefix", "")` fallback) so operators can correlate logs to the repository and event.

### Fix Focus Areas
- webhook_server/libs/github_api.py[1132-1134]

Suggested change: prepend the prefix, e.g.:
```python
prefix = getattr(self, "log_prefix", "")
self.logger.warning(f"{prefix} welcome-extra-info exceeds 10KB limit ({_byte_len} bytes). Ignoring.")
```
(or use `self.log_prefix` directly if always present here).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Description

In _repo_data_from_config(), the oversized welcome-extra-info guard encodes the same string to
UTF-8 twice (once for the > 10240 check and again to compute _byte_len). This is unnecessary
duplicate work and can be simplified by computing the byte length once.

Code

webhook_server/libs/github_api.py[R1130-1132]

+        elif len(self.welcome_extra_info.encode("utf-8")) > 10240:
+            _byte_len = len(self.welcome_extra_info.encode("utf-8"))
+            self.logger.warning(f"welcome-extra-info exceeds 10KB limit ({_byte_len} bytes). Ignoring.")

Relevance

⭐⭐⭐ High

Team previously accepted eliminating duplicate string operations for reuse in github_api.py (PR
#961).

PR-#961

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The referenced lines show encode("utf-8") being called in the elif condition and immediately
again to compute _byte_len for logging, duplicating the same work.

webhook_server/libs/github_api.py[1125-1133]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The oversized `welcome-extra-info` guard performs two `encode("utf-8")` calls on the same string back-to-back.

### Issue Context
This code runs when loading repo config and checking the 10KB limit.

### Fix Focus Areas
- webhook_server/libs/github_api.py[1130-1132]

### Suggested fix
Compute the UTF-8 byte length once (e.g., `byte_len = len(self.welcome_extra_info.encode("utf-8"))`) and reuse it for both the comparison and the log message.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools